1. Field of the Invention
The present invention relates, in general, to video game development and communications between development tools and video game platforms, and, more particularly, to systems and methods for providing real time feedback to video game developers on changes or additions to running video games.
2. Relevant Background
The video game market has moved from a smaller niche market to a multi-billion dollar market. The demand for new video games is growing rapidly as the size and demographics of game players continues to expand. Also, video games used to be made for only one or two game platforms, but now there is a demand for video games that can be sold on numerous platforms including standalone game consoles, computers, handheld portable gaming devices, and other electronic devices such as cellphones, digital music players, and personal digital assistants (PDAs). As a result, there is significant competition among game developers to create video games to meet the growing demand in a timely and efficient manner and, often, for these games to be able to run as desired on differing platforms or devices.
Large-scale, commercial video games are typically created by large development teams with the development process taking 1 to 3 years and costing millions of dollars. A typical development team may include producers to oversee production, game designers, artists, programmers, level designers, sound engineers, and testers with some team members handling more than one role. The development team works in a collaborative manner to create game content (or game assets) and game code, which together may be thought of as a game application, that can be run by a gaming engine on a particular game platform to provide the game to a player. For example, programmers may write new source code, artists may develop game assets such as characters or scene objects, coloring schemes, textures, 3D models of game elements, and the like, sound engineers may develop sound effects and music, writers may create character dialog, and level designers may create advanced and eye-catching levels.
To support these team members, numerous game development tools, such as Microsoft XNA, Maya from Autodesk, Inc., and the like, are now available for use in designing and creating game content including creating and modeling characters and even for defining game logic (e.g., how high a character jumps, how much life does a character gain or lose based on a game event, how fast does a character or game element move, and so on). However, typically a complete engine has to be purchased, which causes most game developers to try to build their own tools. Additionally, each video game console or platform developer typically will make a software development kit (or SDK or devkit) available to game developers, and each SDK may include applications or tools that are useful in creating new video games. Each SDK may also include a communications library and/or interface (e.g., platform communications data) to facilitate communications with a game platform (e.g., the platform running a game under current development or running a built game for testing or use by a developer to see how a new character, asset, game parameter, or the like is working in the game).
Currently, development tools used in the video game industry rarely communicate with each other and, if they do, the tools typically communicate and function using a one-to-one connection. Specifically, the tool communicates with a game running on a particular video game platform with a connection between the tool running on a developer's workstation and the game platform. For example, the development tool may generate a platform client on the workstation to provide an interface with the running game, and the tool may be required to manage a communication socket to support these communications. Each game platform typically utilizes differing interfacing and communication protocols (or at least have some differences), and each development tool is required to understand how to communicate with each game platform that may be used with the tool. Presently, a game developer may be working on a video game that needs to operate on more than one game platform, and the development for each platform often occurs along parallel paths as it is desirable (or required) for games to be released concurrently for each of the game platforms.
Developing or “authoring” a video game is often time consuming for members of the development team, and computer processing time during the game creation and modification is often a large percentage of development time. For example, the present development process in the video game industry involves a designer, programmer, artist, or other team member using a development tool to change an existing, or to create a new, game asset such as a game object, a texture of an object or scenery element, an animation or character, or the like. The development team member then processes this data to create a new game build and then uploads it to a particular game platform or console. They can then see their changes or additions in the running game on the platform. If additional changes are required, the process is repeated with altering game assets through operation of a game development tool on their workstation and rebuilding and running the modified video game application with a game engine on the game platform.
This iterative process is time consuming and also requires considerable amounts of processing time to create new builds or versions of the video game application, and the problem is amplified when there are numerous small changes that need to be made or many repetitive changes or additions that need to be made to a game level or scene as the developer quickly becomes frustrated with the tedious task of making minor changes and having to reprocess the game application to view the changes. Further, the process has to be repeated for each intended video game platform because a change or modification to a game asset that “works” or is effective on one platform may not be acceptable on another platform. For example, a coloring change or a lighting change to a video game may produce a desirable effect when the video game is run on one platform while the same change may produce a different and unacceptable effect on a second platform (e.g., a game development tool may allow setting lighting at 5 on a scale from 1 to 10 but each platform or game engine may translate this differently to produce differing effects). Another issue is that different game development tools may have to be run or used to alter differing portions or sets of the game assets, and, typically, this has required separate game builds or game asset processing to view the revised video game.
Some companies have created products designed to be used as the central hub of game content authoring, but this has not resolved all editing and modifying issues. Another attempt to address the time consuming editing or modifying problems of game development has been to try to build the tools into the game engine. However, this approach is generally undesirable as it increases the chances of work-stopping bugs in the tools as it ties operation of all of the tools together, and this approach has been resisted by game platform developers as it complicates the game engine and its operations. This only allows the content creator to view the created assets inside the tool, and while it is closer to a running game, it is not actually the same as the game running on a target platform, which can fool a game designer or developer.
Hence, there remains a need for improved methods for authoring a video game. Preferably, such methods and systems support use of existing (and to be developed) video game development tools and would reduce the amount of time spent by developers in creating new game assets and in performing modifications to a previously built video game.